アクションと検証

Eggplantで自動化を行う上で原則とすべき事項の1つは、SUT上で実行されたアクションが期待通りであったかという観点にて、検証処理を設定する事です。ここで確認するのは、アクションの結果としてテキストや画像が見つかるかという点です。事実上、これは実際のユーザーがシステムの操作を行う際に、イベントが正しく完了したかの判断を行う方法と同様です。

この利点は以下の通りです

自動化が先走ったり、同期がとれなくなったりしないようにする。
SUT の性能（ネットワーク速度、システムリソースなど）のばらつきに対応して、プロセスを進めるかを判断する。
テストの成否結果を示す明確な基準を設定する。

❌DON'T:

以下のビデオは、コードにバリデーションが適用されていないと何が起こるかを示しています：

ユーザーはクリックに続けてタイプテキストなどを試みます。
各コード行は即座に実行されるため、テストされるシステムの挙動が追いつかなくなると、そのズレが定義された処理の不成立を招きます（ブラウザの起動とURLの入力）。
この問題を解決するために、ユーザーはロード時間などへの対応として待機時間を設定することができます。しかしこの方法では、実行の長時間化を招いてしまいます。
ハードウェイトは便利なツールですが、スクリプトの速度に悪影響を与え、SUTの異なるロード速度や挙動に柔軟に対応できず、メンテナンスコストがかかります。

✅DO:

以下のビデオは、推奨例で示された技術を実装することにより、自動化の堅牢性と速度が大幅に向上していることを示しています：

ユーザーは"ダイナミックウェイト"（例えば「WaitFor 10,...」）を追加しました。
このアプローチははるかに堅牢な結果をもたらします。
このソリューションはSUTのパフォーマンスに幅がある時に、UIの状態に対応した処理を行います。
長期的なメンテナンスは大幅に少なくなります。

画像とOCR検索、ダイナミックウェイトコマンドを含む詳細な説明については、このリンクを参照してください。

学んだことの要約

各アクションの後に都度確認を行うことは、テスト結果の判定材料とするだけでなく、テスト中の表示内容と自動処理が同期することを担保するための重要な手法です。

❌非推奨例

✅推奨例

// Step 1
click image:"chrome"
wait 5
typetext "https://demo.nopcommerce.com/",returnkey
wait 10

// Step 2
moveto image:"Computers"
wait 1
click image:"Desktops"
wait 10

// Step 3
click image:"DigitalStormVANQUISH"
wait 10

// Step 4
click image:"ADDTOCART"
wait 4

// Step 5
moveto image:"Basket"
wait 1
click image:"GOTOCART"
assert that imagefound(0,"DigitalStormVANQUISH3CustomPerformance")

// Step 1
click image:"chrome"
waitfor 20, image:"refresh"

typetext "https://demo.nopcommerce.com/",returnkey
waitfor 20, image:"nopCommerce"

// Step 2
moveto image:"Computers"
click image:"Desktops"
waitfor 20, "HomeComputersDesktops"

// Step 3
click image:"DigitalStormVANQUISH"
waitfor 20, image:"DigitalStormVANQUISH3CustomPerformancePC"

// Step 4
click image:"ADDTOCART"
waitfor 20,image:"Succesfully Added to Cart"

// Step 5
moveto image:"Basket"
click image:"GOTOCART"
waitfor 20, image:"Shoppingcart"
assert that imagefound(0,"DigitalStormVANQUISH3CustomPerformance")

画像フォルダ:

この利点は以下の通りです​

学んだことの要約​

この利点は以下の通りです

学んだことの要約